Nội dung của đây là gì?
Quá trình chuyển đổi từ Manifest V2 sang Manifest V3 có một thay đổi cơ bản. Trong Manifest V2, các tiện ích hoạt động ở một trang nền. Trang nền quản lý quá trình giao tiếp giữa tiện ích và trang web. Thay vào đó, Manifest V3 sử dụng trình chạy dịch vụ.
Trong bài đăng này, chúng ta sẽ đi sâu vào vấn đề kiểm thử trình chạy dịch vụ tiện ích. Cụ thể, chúng ta xem cách đảm bảo sản phẩm hoạt động chính xác trong trường hợp một nhân viên dịch vụ bị tạm ngưng.
Chúng tôi là ai?
eyeo là một công ty chuyên hỗ trợ hoạt động trao đổi giá trị trực tuyến một cách cân bằng và bền vững cho người dùng, trình duyệt, nhà quảng cáo và nhà xuất bản. Chúng tôi có hơn 300 triệu người dùng lọc quảng cáo trên toàn cầu cho phép hiển thị Quảng cáo được chấp nhận, một tiêu chuẩn quảng cáo được lấy từ các nguồn độc lập, giúp xác định xem một quảng cáo có được chấp nhận và không gây gián đoạn hay không.
Nhóm Công cụ tiện ích của chúng tôi cung cấp công nghệ lọc quảng cáo hỗ trợ một số tiện ích trình duyệt chặn quảng cáo phổ biến nhất trên thị trường, như AdBlock và Adblock Plus với hơn 110 triệu người dùng trên toàn thế giới. Ngoài ra, chúng tôi còn cung cấp công nghệ này dưới dạng thư viện nguồn mở, cung cấp công nghệ này cho các tiện ích mở rộng khác của trình duyệt để lọc quảng cáo.
Trình chạy dịch vụ là gì?
Trình chạy dịch vụ tiện ích là trình xử lý sự kiện trung tâm của tiện ích trình duyệt. Các thư viện này chạy độc lập ở chế độ nền. Nhìn chung, điều này là bình thường. Chúng ta có thể làm hầu hết những việc cần làm trên trang nền trong trình chạy dịch vụ mới. Tuy nhiên, có một vài thay đổi so với trang nền:
- Trình chạy dịch vụ chấm dứt khi không được sử dụng. Việc này đòi hỏi chúng ta phải duy trì trạng thái ứng dụng thay vì dựa vào các biến toàn cục. Điều này có nghĩa là bất kỳ điểm truy cập nào trong hệ thống của chúng tôi đều phải được chuẩn bị để được gọi trước khi khởi động hệ thống.
- Bạn phải đính kèm trình nghe sự kiện trước khi chờ mọi lệnh gọi lại không đồng bộ. Trình chạy dịch vụ bị tạm ngưng vẫn có thể nhận các sự kiện mà đã đăng ký. Nếu trình nghe của sự kiện không được đăng ký trong lượt đầu tiên của vòng lặp sự kiện, trình nghe này sẽ không nhận được sự kiện nếu sự kiện đó đánh thức trình chạy dịch vụ.
- Việc chấm dứt trạng thái rảnh có thể làm gián đoạn đồng hồ hẹn giờ trước khi hết thời gian.
Khi nào trình chạy dịch vụ bị tạm ngưng?
Đối với Chrome 119, chúng tôi nhận thấy trình thực thi dịch vụ bị tạm ngưng:
- Sau khi không nhận được sự kiện hoặc không gọi API tiện ích trong 30 giây.
- Tuyệt đối không nếu công cụ cho nhà phát triển đang mở hoặc bạn đang sử dụng thư viện kiểm thử dựa trên ChromeDriver (xem yêu cầu về tính năng).
- Nếu bạn nhấp vào Stop (Dừng) trong chrome://serviceworker-internals.
Để biết thêm thông tin mới nhất, hãy tham khảo Vòng đời của trình chạy dịch vụ.
Tại sao việc kiểm thử tính năng này lại gặp vấn đề?
Tốt nhất là bạn nên có hướng dẫn chính thức về “cách kiểm thử worker dịch vụ một cách hiệu quả” hoặc các ví dụ về kiểm thử hoạt động. Trong quá trình làm việc thử nghiệm nhân viên dịch vụ, chúng tôi gặp phải một số thách thức:
- Chúng ta có trạng thái trong tiện ích thử nghiệm. Khi trình chạy dịch vụ dừng, chúng ta sẽ mất trạng thái và các sự kiện đã đăng ký. Chúng ta sẽ duy trì dữ liệu như thế nào trong quy trình kiểm thử?
- Nếu trình chạy dịch vụ có thể bị tạm ngưng bất cứ lúc nào, chúng tôi cần kiểm tra để đảm bảo tất cả tính năng đều hoạt động khi bị gián đoạn.
- Ngay cả khi chúng tôi đưa vào kiểm thử một cơ chế tạm ngưng ngẫu nhiên trình thực thi dịch vụ, thì trình duyệt vẫn không có API nào để tạm ngưng trình thực thi một cách dễ dàng. Chúng tôi đã yêu cầu nhóm W3C thêm tính năng này nhưng cuộc trò chuyện vẫn đang diễn ra.
Tạm ngưng trình chạy dịch vụ kiểm thử
Chúng tôi đã thử một số phương pháp để kích hoạt việc tạm ngưng trình chạy dịch vụ trong quá trình kiểm thử:
| Phương pháp | Vấn đề về phương pháp |
| Đợi một khoảng thời gian tùy ý (ví dụ: 30 giây) | Điều này khiến việc kiểm thử diễn ra chậm và không đáng tin cậy, đặc biệt là khi chạy nhiều kiểm thử. Nó không hoạt động khi sử dụng WebDriver vì WebDriver sử dụng API Công cụ cho nhà phát triển của Chrome và trình chạy dịch vụ không bị tạm ngưng khi Công cụ cho nhà phát triển đang mở. Ngay cả khi có thể bỏ qua, chúng ta vẫn phải kiểm tra xem trình chạy dịch vụ có bị tạm ngưng hay không và chúng ta không có cách nào để thực hiện việc đó. |
| Chạy một vòng lặp vô hạn trong trình chạy dịch vụ | Theo thông số kỹ thuật, điều này có thể dẫn đến chấm dứt tùy thuộc vào cách trình duyệt triển khai chức năng này. Chrome không chấm dứt trình chạy dịch vụ trong trường hợp này nên chúng ta không thể kiểm thử trường hợp trình chạy dịch vụ bị tạm ngưng. |
| Có thông báo trong trình chạy dịch vụ để kiểm tra xem tác vụ đã bị tạm ngưng chưa | Việc gửi tin nhắn sẽ đánh thức nhân viên dịch vụ. Bạn có thể dùng tính năng này để kiểm tra xem trình chạy dịch vụ có đang ngủ hay không. Tuy nhiên, tính năng này sẽ làm hỏng kết quả đối với các lần kiểm thử cần thực hiện kiểm tra ngay sau khi tạm ngưng trình chạy dịch vụ đó. |
| Loại bỏ quy trình của trình chạy dịch vụ bằng cách sử dụng chrome.processes.terminate() | Trình chạy dịch vụ cho tiện ích chia sẻ quy trình với các phần khác của tiện ích, vì vậy việc loại bỏ quy trình này bằng cách sử dụng chrome.process.terminate() hoặc GUI trình quản lý quy trình của Chrome không chỉ loại bỏ trình chạy dịch vụ mà còn cả trang tiện ích. |
Chúng tôi đã kết thúc một bài kiểm thử kiểm tra cách mã phản hồi với trình chạy dịch vụ bị tạm ngưng bằng cách yêu cầu Selenium WebDriver mở chrome://serviceworker-internals/ rồi nhấp vào nút "dừng" của trình chạy dịch vụ.
Đây là lựa chọn tốt nhất từ trước đến nay, nhưng chưa lý tưởng vì các kiểm thử Mocha (chạy trên một trang tiện ích) không thể tự thực hiện, do đó, chúng cần liên lạc lại với chương trình nút WebDriver của chúng ta. Điều này có nghĩa là các chương trình kiểm thử này không thể chạy chỉ bằng tiện ích; chúng phải được kích hoạt bằng cách sử dụng Selenium WebDriver.
Dưới đây là sơ đồ về cách chúng tôi giao tiếp với API trình duyệt thông qua các quy trình khác nhau và ảnh hưởng của việc thêm cơ chế "suspend Service worker" (trình thực thi dịch vụ tạm ngưng) trên đó.
Trong một quy trình mới tạm ngưng dịch vụ (màu xanh dương), chúng tôi đã thêm Selenium WebDriver để tạm ngưng "nhấp" thông qua giao diện người dùng, kích hoạt một thao tác trong API trình duyệt.
Điều đáng nói là đã xảy ra lỗi của Chrome, trong đó việc thực hiện việc này bằng Selenium WebDriver khiến trình chạy dịch vụ không thể bắt đầu lại. Sự cố này đã được khắc phục trong Chrome 116 và rất may là cũng có một giải pháp: việc đặt Chrome tự động mở Công cụ cho nhà phát triển trên mỗi thẻ sẽ giúp trình chạy dịch vụ khởi động đúng cách.
Đây là phương pháp chúng tôi đang sử dụng khi thử nghiệm mặc dù nó không lý tưởng vì nhấp vào nút có thể không phải là API ổn định và việc mở Công cụ cho nhà phát triển (đối với các trình duyệt cũ hơn) dường như có chi phí hiệu suất.
Làm cách nào để đề cập đến toàn bộ chức năng? Kiểm thử độ mờ
Khi đã có cơ chế kiểm tra tính năng tạm ngưng, chúng tôi phải quyết định cách đưa cơ chế đó vào bộ kiểm tra tự động. Chúng tôi chạy các quy trình kiểm thử tiêu chuẩn trong một môi trường mà trước mỗi lần tương tác với trang nền, trình chạy dịch vụ bị tạm ngưng khi WebDriver nhấp vào Stop (Dừng) trên trang chrome://serviceworker-internals/.
Chúng tôi chạy hầu hết (không phải tất cả) thử nghiệm vì cơ chế tạm ngưng chưa hoàn toàn ổn định và đôi khi gây ra hiện tượng không ổn định. Ngoài ra, việc chạy tất cả các bộ kiểm thử ở chế độ mờ mất nhiều thời gian. Vì vậy, thay vì bao gồm mọi trường hợp "tương tự", chúng tôi đã chọn các đường dẫn quan trọng nhất để kiểm thử ở chế độ mờ. Điểm đáng chú ý là việc chạy kiểm thử chức năng ở chế độ "fuzz" đồng nghĩa với việc chúng ta phải tăng thời gian chờ của kiểm thử vì việc tạm ngưng và khởi động lại trình chạy dịch vụ sẽ mất thêm thời gian.
Các bài kiểm thử này có giá trị như lượt chuyển đầu tiên ở mức độ thô, nêu bật nhiều chỗ mã không thành công nhưng có thể không nhất thiết phải phát hiện hết những chi tiết nhỏ mà việc tạm ngưng trình chạy dịch vụ có thể khiến mọi thứ bị lỗi.
Trong nội bộ, chúng tôi gọi các loại thử nghiệm này là "Thử nghiệm mờ". Thông thường, kiểm thử mờ là khi bạn gửi dữ liệu đầu vào không hợp lệ vào chương trình của mình và đảm bảo rằng chương trình đó phản hồi một cách hợp lý, hoặc ít nhất là không gặp sự cố. Trong trường hợp của chúng ta, "dữ liệu đầu vào không hợp lệ" là trình chạy dịch vụ bị tạm ngưng bất cứ lúc nào và "hành vi hợp lý" mà chúng ta mong muốn là chức năng lọc quảng cáo phải tiếp tục hoạt động như trước. Đây không phải là dữ liệu đầu vào thực sự không hợp lệ vì đây là hành vi dự kiến trong Manifest V3, nhưng điều này đã không hợp lệ trong Manifest V2 nên có vẻ như có thuật ngữ hợp lý.
Tóm tắt
Trình chạy dịch vụ là một trong những thay đổi lớn nhất trong Manifest V3 (bên cạnh các quy tắc declarativeNetRequest). Quá trình di chuyển sang Manifest V3 có thể đòi hỏi bạn phải thay đổi mã trong các tiện ích của trình duyệt cũng như phương pháp kiểm thử mới. Ngoài ra, nhà phát triển tiện ích có trạng thái cố định cũng phải chuẩn bị tiện ích để xử lý việc tạm ngưng trình chạy dịch vụ không mong muốn theo cách linh hoạt.
Rất tiếc là không có API nào để xử lý việc tạm ngưng một cách dễ dàng phù hợp với trường hợp sử dụng của chúng tôi. Do muốn kiểm tra độ mạnh của cơ sở mã của tiện ích dựa trên cơ chế tạm ngưng ở giai đoạn đầu, nên chúng tôi phải tìm cách giải quyết vấn đề này. Các nhà phát triển tiện ích khác gặp phải những thách thức tương tự có thể sử dụng giải pháp này. Giải pháp này tuy tốn nhiều thời gian trong giai đoạn phát triển và bảo trì, nhưng rất đáng để chúng tôi có thể đảm bảo rằng các tiện ích của chúng tôi có thể hoạt động thành công trong môi trường mà nhân viên dịch vụ thường xuyên bị tạm ngưng.
Mặc dù đã có sự hỗ trợ cơ bản cho việc tạm ngưng trình chạy dịch vụ, nhưng chúng tôi vẫn muốn hỗ trợ nền tảng tốt hơn cho việc kiểm thử trình chạy dịch vụ trong các tiện ích trong tương lai, vì tính năng này có thể giúp giảm đáng kể thời gian thực thi kiểm thử và công sức bảo trì.